I've also noticed that perf_event_mmap_page is missing. Here's a possible translation:

pub const perf_event_mmap_page = extern struct {
    version: u32,
    compt_version: u32,
    lock: u32,
    index: u32,
    offset: i64,
    time_enabled: u64,
    time_running: u64,
    capabilities: extern union {
        capabilities: u64,
        cap: packed struct {
            bit0: u1,
            bit0_is_deprecated: u1,
            user_rdpmc: u1,
            user_time: u1,
            user_time_zero: u1,
            user_time_short: u1,
            ____res: u58,
        },
    },
    pcm_width: u16,
    time_shift: u16,
    time_mult: u32,
    time_offset: u64,
    time_zero: u64,
    size: u32,
    __reserved_1: u32,
    time_cycles: u64,
    time_mask: u64,
    __reserved: [116 * 8]u8,
    data_head: u64,
    data_tail: u64,
    data_offset: u64,
    data_size: u64,
    aux_head: u64,
    aux_tail: u64,
    aux_offset: u64,
    aux_size: u64,
};

I'm not including it yet in this PR because the capabilities field adds a small naming/layout decision — the Zig version would need to be accessed like:

_ = m.capabilities.capabilities;
// or
_ = m.capabilities.cap.bit0;

while in c would be

m.capabilities;
// or
m.cap_bit0;

Since this is my first PR to Zig, I’d rather not make that call on my own. If there’s a preferred naming or layout approach here, I’d be glad to follow up with a separate PR or add it to this one as a second commit.

Here's a possible translation

I think capabilities should just be a packed struct - no need for the union.

I added the perf_event_mmap_page definition and removed the default values for perf_event_header because this struct will be bitcasted to a memory location, making the default initializations unnecessary.

I also noticed that the current perf_event_attr definition is outdated; the struct now has more flags and additional fields. See the Linux current UAPI and Zig std definition for reference. If needed, I’m happy to update that too—just let me know if you prefer it in this PR or a separate one.

If needed, I’m happy to update that too—just let me know if you prefer it in this PR or a separate one.

Sure, might as well include that if you feel like it.